The present invention is a lightweight, service-oriented computer software framework and method that provides a means to synchronize common data between applications with unique schemas on different databases. The invention provides a lightweight publish/subscribe (pub/sub) messaging framework for use by an enterprise that desires its distributed applications and other disparate systems to synchronize their common data without requiring them to share databases or have similar database schemas.
A company may have a single customer who purchases a number of different products or services such as long distance service, wireless phone service, cable television service, etc. Each business unit within the company providing these individual services may have a separate computing system hosting a variety of business applications, which in turn may interact with any number of lower level datastores to create, retrieve, update, and delete data processed by the application. Much of the data residing in the various datastores will be common to each customer. In other words, the long distance service datastores may contain data for the customer such as name, address, billing information, etc. that is the same as (i.e., common to) data contained in the wireless phone service datastores and the cable television datastores. A need exists for an efficient way to synchronize the common customer data across the various computing systems of the entire enterprise.
One solution is to limit the data to a single set (which may reside on any number of datastores) and have all business applications enterprise wide access data from the single set. In other words, there is only one set of data for a given customer, and therefor the data must only be updated once. Since there is only one set of data, there is no need to synchronize different data sets. For example, a customer""s address could be placed in a single database. Should the customer""s address change, the database need only be updated once with the customer""s new address, and subsequent access by any application would produce the correct, updated customer address. The problem with a common data set is that most enterprise wide computing systems are a conglomeration of separate and distinct computing systems, each of which has its own datastores and schemas (i.e., methods and formats) for storing data. Therefore, an attempt to converge a large computing system to a common set of data would be extremely burdensome.
Messaging products such as Oracle Inc.""s Advanced Queuing (AQ) messaging technology, which is included with Oracle products such as Oracle8 database release 8.0.5 with Advanced Queuing and Objects Options, have attempted to address data synchronization on the database level. In brief, AQ provides a means for relational databases operating on a common computer system to exchange data. For example, applications with unique schemas on independent Oracle databases could synchronize their common data by registering message xe2x80x98triggersxe2x80x99 on their tables of interest and defining the conditions necessary to fire these triggers whenever data was updated. Thus, whenever relevant data was updated, these xe2x80x98triggersxe2x80x99 would create rigid messages or data structures capturing the content of the updated information, call methods/packages on structured query language (SQL) interfaces to Oracle Advanced Queues, and send the messages/data structures previously created. For applications with similar schemas on independent Oracle databases, synchronization of common data could simply be achieved through database replication.
The problem with attempting to synchronize data at the database level is that the databases must reside on the same computer system, for example a local area network/server, in order for the databases to exchange information. Database level messaging is not suitable for synchronizing data on an enterprise wide scale where data resides in a plurality of databases across a variety of computing systems. The current invention addresses the need for an enterprise-level framework and method to synchronize common data residing on plurality of different databases. The invention provides distributed access to a data synchronization means, thereby allowing individual systems and applications to structure their data storage schemas to fit their own purposes such as to achieve efficiency in development or performance.
The current invention makes the task of updating and synchronizing data much simpler from an application perspective. The application, through use of the invention, need only send data synchronization messages to a single outbox queue (which in turn will propagate the messages broadly) and need only receive data synchronization messages from a single inbox queue, thereby avoiding burdensome publication and subscribe tasks such as executing wide-distribution of messages, updating and maintaining detailed subscriber lists, etc. Thus, the application runs more efficiently by isolating itself through use of the current invention.
The present invention discloses a method for synchronizing data, comprising instantiating a first data synchronization service object and a second data synchronization object, the first data synchronization service object being connected to a first datastore and the second data synchronization service object being connected to a second datastore; sending a data synchronization message containing relevant information from the first data synchronization service object to an outbox queue on the first datastore; propagating the data synchronization message from the outbox queue on the first datastore to an inbox queue on the second datastore; receiving the data synchronization message from the inbox queue on the second datastore to the second data synchronization object; and persisting the relevant information in the second datastore.
The present invention further discloses a data synchronization framework, comprising a data synchronization service object connected to an underlying datastore, the data synchronization service object having a method to send an outgoing synchronization message to the datastore and a method to retrieve an incoming synchronization message from the datastore; and a persistence component for persisting relevant information contained in a retrieved data synchronization message to the underlying datastore in response to a persistence request from the synchronization service object. In a preferred embodiment, the datastore is a relational database having an inbox queue and an outbox queue.